Computer networks have developed into an integral part of society and the economy. Network users obtain access from their host computer with dial-up capability to another computer with which to communicate through a variety of systems currently available. A user transmits a request or call from an access point across a medium to the remote site. The call will be identified by selected attributes in an access request data packet that may be used by the network accounting management. To facilitate access by authorized call-in users and network subscribers, a variety of network servers have been developed that may include computer hardware, software and/or firmware. These servers are frequently designed to handle specific tasks within the network and operate with a dedicated database. A call-in user may thus be dependent on more than one server for continued access to the network, and if one server fails while others continue to operate, the user may nonetheless be disconnected from the network and be forced to establish a new connection even though the network remains active.
The time consumed from repeated interruptions can lead to diminished productivity and severe frustration if critical data are denied or corrupted due to a recalcitrant server. Consequently, network administrators have sought to address this and other concerns by ensuring high reliability for servers and establishing backup systems. However, a backup server without access to the call's status from the identification in the data packet may be unable to maintain a previously established call, resulting in the call being cut off. Consequently, aside from efforts to ensure high reliability of servers, the industry also requires a backup system with the ability to hand-off a call-in user's network connection from a server that has failed to a backup server by ensuring that call identification information is received by a backup server in a timely fashion.
A connection from an access point to a network at a point of presence (PoP) may be maintained by an internet service provider (ISP) or a telephone company using communications media such as a public switched telephone network (PSTN), integrated services digital network (ISDN), or a cable television system, using one of several available mechanisms or protocols. Such protocols include the decentralized Institute of Electrical & Electronic Engineers (IEEE) standard 802.3 called Ethernet™, the token ring IEEE standard 802.5 incorporating a special bit-pattern to control transmission order, the asynchronous digital subscriber line (ADSL) under the American National Standards Institute (ANSI) T1.413 standard, the hybrid fiber coax (HFC) used by cable television providers, or others as is well known in the art. An access point may contain a variety of server types for particular functions. These types include the authentication, authorization and accounting (AAA) server, the network access server (NAS), the resource pool manager server (RPMS), the home gateway router (HGR), the digital subscriber line aggregation multiplexer (DSLAM), along with many others well known in the art.
A call-in user seeking a connection to the network may place a call across telephone lines or other media to a NAS through a particular port of the NAS, such as a modem port or ISDN port. The NAS answers the call, becoming coupled to the user, and sends the call type and dialed number information service (DNIS) information to the RPMS, which matches the combination to a call discrimination table and compares the network resources available to the session counts. Call types include speech, digital and others known in the art. The call is rejected if the call type-DNIS combination appears in the call discrimination table. If the customer profile session limits exceed threshold values, the call may be rejected or assigned a busy signal. If the call is accepted, it is assigned to the NAS that answered it. A RPMS may provide resource management, dial services and call discrimination for a regional PoP or for a NAS connected to multiple ports.
A RPMS enables telephone companies and ISPs to count, control, manage and provide accounting data on shared resources for wholesale virtual private dial-up network (VPDN) and retail dial network services across one or more NAS stacks. By tracking threshold access limits, the RPMS verifies to the NAS that there exist sufficient network resources to enable a user calling in to become connected to the network (provided that the user has authorization). An illustration of the logic used by a RPMS can be seen in the flow diagram 10 of FIG. 1. An input 12 containing call type-DNIS information is provided to a call discriminator query 14, which compares the information to a series of discriminators implemented as a call discrimination table. If the call matches the table, it is unauthorized and the call is treated to rejection 16. If no match is found, the DNIS customer profile is queried 18, and if none is found, a default profile is queried 20. If no default match is found, the call may be rejected 22. If the DNIS customer profile exists after query 18, the connection threshold is queried 24, and if not reached, or if a default customer match is found in the default query 20, then the number of resources is queried 26. If sufficient resources are available, the call may be answered 28, whereupon the VPDN group is verified 30.
If the call does not match the VPDN group, a first retail query is performed 32, and if refused, the call is rejected 34. If retail is accepted, the call is processed at retail cost 36. If the call matches the VPDN group, the domain name in the DNIS is queried 38. If the domain name does not match, a second retail query is performed 40. If refused, the call is rejected 42, and if accepted the call is processed at retail cost 44. If the domain name query 38 matches, the session and overflow thresholds are queried 46. If the thresholds are exceeded, the call is rejected 48, and if not a tunnel is negotiated 50.
Returning to the maximum connections query 24, if the connection threshold has been reached, the overflow availability is queried 52, and if exceeded, the call may be rejected 54. If availability exists, the availability of resources is queried 56. If the resources available queries 26 or 56 are negative, the call may be rejected 58. If resources are available, the call is answered 60, with continued procedures to the VPDN group verification query 30, and so forth.
The RPMS enables shared resources to be used across multiple NASes for various resource allocation schemes (performing session counting on a group level). For example, NAS resource groups may be combined with different modem services and call types (such as speech or digital) into resource data assignments. Resource groups may be configured on the NAS and assigned by the RPMS based on customer requirements. The RPMS may use resource management protocol (RMP) software to communicate with the NAS. An illustration of this arrangement is illustrated in FIG. 2A, in which a NAS 62 is featured with RMP installed and connected to a RPMS 64 via a RMP interface 66. The call type-DNIS information transmitted to the RPMS 64 and the approval or rejection response received by the NAS 30 are transferred through the RMP interface 66 using the RMP protocol 68.
The RPMS may be composed of a server platform with appropriate RMP software, along with a Distributed Session Manager (DSM) library installed and linked to the server platform. A RPMS may be a scalable performance architecture (SPARC) hardware platform equipped with DSM software and connected to a database in a memory device physically distinct from the RPMS. The DSM represents a linked library to the RPMS to keep accounting data records for the RPMS, and it maintains session states across multiple servers. The database may hold the customer profiles, system configurations and other desired instrumentation.
A local AAA server may be used in a network architecture incorporating a RPMS for the purpose of tracking users that access the network through calling line identification (CLID) and for creating records of the accounting data related to such users from outside the data communications network. The RPMS may communicate with a local AAA server using an internet authentication protocol, such as Terminal Access Controller Access Control System Plus (TACACS+) or Remote Access Dial-In User Service (RADIUS). In the absence of a local AAA server, the RPMS may provide only DNIS-based wholesale VPDN dial services under the domain name, and a remote AAA server may be used for user call tracking and management. When the call ends, the record for billing purposes may be sent to a report manager server.
As calls are received, the primary RPMS checks session counts to perform session management. These local counts are sent to the backup RPMS for synchronization. When the session counts approach a session limit, the primary RPMS reverses the exchange to get the session count from the backup RPMS for each call, thereby ensuring that an accurate session count is maintained and prevents more users from accessing the network than are permitted, a condition called “over-subscription”. However, this exchange may reduce performance when the customer profile approaches its session limit for resource allocation.
A client NAS may be configured with a list of RPMSes from which to attempt contacting a server on the fail-over list. The message data may be exchanged between a the NAS and the server by the RMP. If the NAS cannot reach the first server on the list, it tries to contact the next server, and so forth. In a typical configuration, the primary RPMS would be first on the list, and the backup RPMS would be the second on the list, with no third server listed. An illustration of this list's use by multiple NASes is depicted in FIG. 2B in which a wide area network (WAN) 70 is connected to a first RPMS labeled “A” 72, a second RPMS labeled “B” 74, both independent of each other, and a backup RPMS labeled “C” 76. A first NAS stack 78 with a first server list for RPMSes “A” and “C” is connected to RPMS “A” 72. A second NAS stack 80 with a second list for RPMSes “B” and “C” is connected to RPMS “B” 74. The NAS stacks 78 and 80 are connected to their respective local RPMSes “A” 72 and “B” 74, respectively through RMP 82, and via the WAN 70 to RPMS “C” 76. If RPMS “A” 72 fails, the first list on the first NAS stack 78 would “roll over” or transfer resource management to RPMS “C” 76. Similarly, if RPMS “B” 74 fails, the second list on the NAS stack 80 would likewise proceed to RPMS “C” 76. However, if the backup RPMS lacks the information for call reconstruction, current calls may be discontinued.
In the event that either the primary RPMS or its database is unreachable, the call may be interrupted while the NAS initiates a timing switch. If the call is not restored, the switch times out, causing the call to be dropped from the NAS and a busy signal sent to the call-in user. Incorporation of a backup RPMS might initiate new user calls begun subsequent to the primary RPMS access failure, but absent a mechanism to restore the interrupted calls, the continuity of service for previous users would not be feasible. To avoid interruption of a call, the primary and backup servers must be in communication with each other and share information about a call's context as it is updated, thereby consuming valuable communication bandwidth.